리액트의 비결: 재조정 알고리즘과 가상 DOM 비교(Diffing) 심층 분석

`는 다음과 같이 표현될 수 있습니다:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

이것들은 단지 자바스크립트 객체이기 때문에, 생성하고 조작하는 것이 믿을 수 없을 정도로 빠릅니다. 브라우저 API와의 상호작용이 전혀 없으므로 리플로우나 리페인트가 발생하지 않습니다.

가상 DOM은 어떻게 작동하는가?

VDOM은 선언적인 UI 개발 접근 방식을 가능하게 합니다. 브라우저에게 DOM을 단계별로 어떻게 변경할지 지시하는 대신(명령형), 주어진 상태에 대해 UI가 어떻게 보여야 하는지를 단순히 선언합니다(선언형). 나머지는 리액트가 처리합니다.

과정은 다음과 같습니다:

1. 초기 렌더링: 애플리케이션이 처음 로드될 때, 리액트는 UI에 대한 완전한 가상 DOM 트리를 생성하고 이를 사용하여 초기 실제 DOM을 생성합니다.
2. 상태 업데이트: 애플리케이션의 상태가 변경되면(예: 사용자가 버튼을 클릭), 리액트는 새로운 상태를 반영하는 새로운 가상 DOM 트리를 생성합니다.
3. 비교(Diffing): 이제 리액트는 메모리에 두 개의 가상 DOM 트리를 갖게 됩니다: 이전 트리(상태 변경 전)와 새로운 트리입니다. 그런 다음 "비교(diffing)" 알고리즘을 실행하여 이 두 트리를 비교하고 정확한 차이점을 식별합니다.
4. 일괄 처리 및 업데이트: 리액트는 실제 DOM을 새로운 가상 DOM과 일치시키기 위해 필요한 가장 효율적이고 최소한의 작업 집합을 계산합니다. 이러한 작업은 함께 일괄 처리되어 단일의 최적화된 순서로 실제 DOM에 적용됩니다.

업데이트를 일괄 처리함으로써 리액트는 느린 DOM과의 직접적인 상호작용을 최소화하여 성능을 크게 향상시킵니다. 이 효율성의 핵심은 공식적으로 재조정 알고리즘으로 알려진 "비교" 단계에 있습니다.

리액트의 심장: 재조정 알고리즘

재조정(Reconciliation)은 리액트가 최신 컴포넌트 트리에 맞게 DOM을 업데이트하는 과정입니다. 이 비교를 수행하는 알고리즘이 바로 우리가 "비교 알고리즘(diffing algorithm)"이라고 부르는 것입니다.

이론적으로, 한 트리를 다른 트리로 변환하는 데 필요한 최소한의 변환 횟수를 찾는 것은 매우 복잡한 문제이며, 알고리즘 복잡도는 O(n³) 수준입니다 (n은 트리의 노드 수). 이는 실제 애플리케이션에서는 너무 느릴 것입니다. 이 문제를 해결하기 위해 리액트 팀은 웹 애플리케이션이 일반적으로 어떻게 작동하는지에 대한 몇 가지 뛰어난 관찰을 통해 훨씬 빠른 O(n) 시간 복잡도로 작동하는 휴리스틱 알고리즘을 구현했습니다.

휴리스틱: 비교(Diffing)를 빠르고 예측 가능하게 만들기

리액트의 비교 알고리즘은 두 가지 주요 가정 또는 휴리스틱을 기반으로 합니다:

휴리스틱 1: 다른 타입의 엘리먼트는 다른 트리를 생성한다

이것은 첫 번째이자 가장 간단한 규칙입니다. 두 VDOM 노드를 비교할 때, 리액트는 먼저 그들의 타입을 봅니다. 만약 루트 엘리먼트의 타입이 다르면, 리액트는 개발자가 하나를 다른 것으로 변환하려고 의도하지 않았다고 가정합니다. 대신, 더 과감하지만 예측 가능한 접근 방식을 취합니다:

• 전체 이전 트리를 해체하고, 모든 이전 컴포넌트를 마운트 해제하며 그 상태를 파괴합니다.
• 새로운 엘리먼트 타입을 기반으로 완전히 새로운 트리를 처음부터 구축합니다.

예를 들어, 다음과 같은 변경을 생각해 보세요:

이전: <div><Counter /></div>
이후: <span><Counter /></span>

자식 `Counter` 컴포넌트가 동일하더라도, 리액트는 루트가 `div`에서 `span`으로 변경된 것을 봅니다. 리액트는 이전 `div`와 그 안의 `Counter` 인스턴스를 완전히 마운트 해제하고(상태를 잃게 됨), 새로운 `span`과 완전히 새로운 `Counter` 인스턴스를 마운트할 것입니다.

핵심 요약: 상태를 보존하거나 해당 하위 트리의 전체 리렌더링을 피하고 싶다면 컴포넌트 하위 트리의 루트 엘리먼트 타입을 변경하지 마세요.

휴리스틱 2: 개발자는 `key` Prop으로 안정적인 엘리먼트를 명시할 수 있다

이것은 개발자가 이해하고 올바르게 적용해야 할 가장 중요한 휴리스틱일 것입니다. 리액트가 자식 엘리먼트 목록을 비교할 때, 기본 동작은 두 자식 목록을 동시에 순회하며 차이점이 있을 때마다 변경(mutation)을 생성하는 것입니다.

인덱스 기반 비교(Diffing)의 문제점

항목 목록이 있고, 키를 사용하지 않고 목록의 맨 앞에 새 항목을 추가한다고 상상해 봅시다.

초기 목록:

• 항목 B
• 항목 C

업데이트된 목록 ('항목 A'를 맨 앞에 추가):

• 항목 A
• 항목 B
• 항목 C

키가 없으면, 리액트는 간단한 인덱스 기반 비교를 수행합니다:

1. 인덱스 0의 이전 항목('항목 B')과 인덱스 0의 새 항목('항목 A')을 비교합니다. 다르므로 첫 번째 항목을 변경합니다.
2. 인덱스 1의 이전 항목('항목 C')과 인덱스 1의 새 항목('항목 B')을 비교합니다. 다르므로 두 번째 항목을 변경합니다.
3. 인덱스 2에 새 항목('항목 C')이 있는 것을 보고 삽입합니다.

이것은 매우 비효율적입니다. 리액트는 단지 맨 앞에 하나를 삽입하면 될 것을, 불필요한 두 번의 변경과 한 번의 삽입을 수행했습니다. 만약 이 목록 항목들이 자체 상태를 가진 복잡한 컴포넌트였다면, 컴포넌트 간에 상태가 뒤섞이는 심각한 성능 문제와 버그로 이어질 수 있습니다.

`key` Prop의 힘

`key` prop은 해결책을 제공합니다. 이는 엘리먼트 목록을 생성할 때 포함해야 하는 특별한 문자열 속성입니다. 키는 리액트에게 각 엘리먼트에 대한 안정적인 식별자를 제공합니다.

동일한 예제를 이번에는 안정적이고 고유한 키를 사용하여 다시 살펴봅시다:

초기 목록:

• 항목 B
• 항목 C

업데이트된 목록:

• 항목 A
• 항목 B
• 항목 C

이제 리액트의 비교 과정은 훨씬 더 똑똑해집니다:

1. 리액트는 새 목록의 자식들을 보고 'b'와 'c' 키를 가진 엘리먼트를 찾습니다.
2. 'b'와 'c' 키를 가진 엘리먼트가 이미 이전 목록에 존재한다는 것을 알고 있으므로, 단순히 이동시킵니다.
3. 이전에 존재하지 않았던 'a' 키를 가진 새 엘리먼트가 있는 것을 보고, 이를 생성하고 삽입합니다.

이것이 훨씬 더 효율적입니다. 리액트는 단 한 번의 삽입만 수행하면 된다는 것을 정확하게 식별합니다. 'b'와 'c' 키와 관련된 컴포넌트들은 보존되어 내부 상태를 유지합니다.

키에 대한 중요 규칙: 키는 형제 엘리먼트 사이에서 안정적이고, 예측 가능하며, 고유해야 합니다. 배열의 인덱스를 키로 사용하는 것(`items.map((item, index) =>

...

)`)은 목록이 재정렬되거나, 필터링되거나, 중간에 항목이 추가/제거될 수 있는 경우 안티패턴입니다. 이는 키가 없는 것과 동일한 문제를 야기하기 때문입니다. 가장 좋은 키는 데이터베이스 ID와 같이 데이터에서 가져온 고유 식별자입니다.

진화: 스택에서 파이버 아키텍처로

위에서 설명한 재조정 알고리즘은 수년 동안 리액트의 기반이었습니다. 하지만 여기에는 한 가지 주요한 한계가 있었습니다: 동기식이며 블로킹 방식이라는 점입니다. 이 초기 구현은 현재 스택 재조정자(Stack Reconciler)라고 불립니다.

과거 방식: 스택 재조정자 (Stack Reconciler)

스택 재조정자에서는 상태 업데이트가 리렌더링을 유발할 때, 리액트는 전체 컴포넌트 트리를 재귀적으로 순회하고, 변경 사항을 계산하며, DOM에 적용하는 모든 과정을 단일하고 중단 없는 순서로 처리했습니다. 작은 업데이트의 경우 이것은 괜찮았습니다. 하지만 큰 컴포넌트 트리의 경우 이 과정은 상당한 시간(예: 16ms 이상)이 걸려 브라우저의 메인 스레드를 차단할 수 있었습니다. 이는 UI가 응답하지 않게 만들고, 프레임 드롭, 버벅거리는 애니메이션, 그리고 좋지 않은 사용자 경험을 유발했습니다.

리액트 파이버 소개 (리액트 16+)

이 문제를 해결하기 위해, 리액트 팀은 핵심 재조정 알고리즘을 완전히 재작성하는 수년간의 프로젝트에 착수했습니다. 그 결과로 리액트 16에서 출시된 것이 리액트 파이버(React Fiber)입니다.

파이버 아키텍처는 동시성(concurrency)을 가능하게 하도록 처음부터 설계되었습니다. 동시성이란 리액트가 여러 작업을 동시에 처리하고 우선순위에 따라 작업을 전환할 수 있는 능력을 의미합니다.

"파이버"는 작업 단위를 나타내는 순수 자바스크립트 객체입니다. 여기에는 컴포넌트, 그 입력(props), 그리고 출력(자식들)에 대한 정보가 담겨 있습니다. 중단될 수 없었던 재귀적 순회 대신, 리액트는 이제 파이버 노드들의 연결 리스트를 한 번에 하나씩 처리합니다.

이 새로운 아키텍처는 다음과 같은 몇 가지 주요 기능을 가능하게 했습니다:

• 점진적 렌더링: 렌더링 작업을 작은 덩어리로 나누어 여러 프레임에 걸쳐 분산시킬 수 있습니다.
• 우선순위 지정: 다양한 유형의 업데이트에 다른 우선순위 수준을 할당할 수 있습니다. 예를 들어, 사용자가 입력 필드에 타이핑하는 것은 백그라운드에서 데이터를 가져오는 것보다 높은 우선순위를 가집니다.
• 일시 중지 및 중단 가능성: 낮은 우선순위의 업데이트 작업을 일시 중지하여 높은 우선순위의 작업을 처리할 수 있으며, 더 이상 필요 없는 작업은 중단하거나 재사용할 수도 있습니다.

파이버의 두 단계

파이버 하에서 렌더링 프로세스는 두 개의 별개의 단계로 나뉩니다:

1. 렌더/재조정 단계 (비동기): 이 단계에서 리액트는 파이버 노드를 처리하여 "작업 진행 중(work-in-progress)" 트리를 구축합니다. 컴포넌트의 `render` 메서드를 호출하고 비교 알고리즘을 실행하여 DOM에 어떤 변경이 필요한지 결정합니다. 결정적으로, 이 단계는 중단 가능합니다. 리액트는 더 중요한 일을 처리하기 위해 이 작업을 일시 중지했다가 나중에 다시 시작할 수 있습니다. 중단될 수 있기 때문에, 리액트는 일관성 없는 UI 상태를 피하기 위해 이 단계 동안 실제 DOM 변경을 적용하지 않습니다.
2. 커밋 단계 (동기): 작업 진행 중 트리가 완성되면, 리액트는 커밋 단계에 들어갑니다. 계산된 변경 사항을 가져와 실제 DOM에 적용합니다. 이 단계는 동기식이며 중단될 수 없습니다. 이는 사용자가 항상 일관된 UI를 볼 수 있도록 보장합니다. `componentDidMount` 및 `componentDidUpdate`와 같은 생명주기 메서드와 `useLayoutEffect`, `useEffect` 훅은 이 단계에서 실행됩니다.

파이버 아키텍처는 `Suspense`, 동시 렌더링, `useTransition`, `useDeferredValue` 등 리액트의 많은 현대적인 기능들의 기반이며, 이 모든 기능들은 개발자들이 더 반응성 있고 유연한 사용자 인터페이스를 구축하는 데 도움을 줍니다.

개발자를 위한 실용적인 최적화 전략

리액트의 재조정 과정을 이해하면 더 성능 좋은 코드를 작성할 수 있는 힘을 얻게 됩니다. 다음은 몇 가지 실행 가능한 전략입니다:

1. 목록에는 항상 안정적이고 고유한 키를 사용하세요

이것은 아무리 강조해도 지나치지 않습니다. 목록에 대한 가장 중요한 단일 최적화입니다. 데이터에서 고유한 ID(예: `product.id`)를 사용하세요. 목록이 완전히 정적이고 절대 변경되지 않는 경우가 아니라면 배열 인덱스를 사용하는 것을 피하세요.

2. 불필요한 리렌더링을 피하세요

컴포넌트는 상태가 변경되거나 부모가 리렌더링될 때 리렌더링됩니다. 때로는 컴포넌트의 출력이 동일함에도 불구하고 리렌더링되는 경우가 있습니다. 다음을 사용하여 이를 방지할 수 있습니다:

• `React.memo()`: 함수형 컴포넌트를 위한 고차 컴포넌트(HOC)입니다. 컴포넌트의 props를 얕게 비교합니다. props가 변경되지 않았다면, 리액트는 해당 컴포넌트의 리렌더링을 건너뛰고 마지막으로 렌더링된 결과를 재사용합니다.
• `useCallback()`: 컴포넌트 내부에 정의된 함수는 렌더링될 때마다 재생성됩니다. 이 함수들을 `React.memo`로 감싸진 자식 컴포넌트에 props로 전달하면, 함수 prop이 기술적으로 매번 새로운 함수이기 때문에 자식 컴포넌트가 리렌더링됩니다. `useCallback`은 함수 자체를 메모이제이션하여, 의존성이 변경될 때만 함수가 재생성되도록 보장합니다.
• `useMemo()`: `useCallback`과 유사하지만 값을 위한 것입니다. 비용이 많이 드는 계산 결과를 메모이제이션합니다. 계산은 의존성 중 하나가 변경된 경우에만 다시 실행됩니다. 이는 렌더링마다 비용이 많이 드는 계산을 방지하고, props로 전달되는 안정적인 객체/배열 참조를 유지하는 데 유용합니다.

3. 스마트한 컴포넌트 구성

컴포넌트를 구조화하는 방식은 성능에 상당한 영향을 미칠 수 있습니다. 컴포넌트 상태의 일부가 자주 업데이트된다면, 그렇지 않은 부분과 분리하도록 노력하세요.

예를 들어, 자주 변경되는 입력 필드로 인해 전체 컴포넌트가 리렌더링되는 단일의 큰 컴포넌트를 두는 대신, 해당 상태를 그 자체의 더 작은 컴포넌트로 분리하세요. 이렇게 하면 사용자가 타이핑할 때 작은 컴포넌트만 리렌더링됩니다.

4. 긴 목록 가상화하기

수백 또는 수천 개의 항목이 있는 목록을 렌더링해야 하는 경우, 적절한 키를 사용하더라도 한 번에 모든 항목을 렌더링하는 것은 느리고 많은 메모리를 소비할 수 있습니다. 해결책은 가상화(virtualization) 또는 윈도잉(windowing)입니다. 이 기술은 현재 뷰포트에 보이는 작은 부분 집합의 항목만 렌더링하는 것을 포함합니다. 사용자가 스크롤하면 이전 항목은 마운트 해제되고 새 항목이 마운트됩니다. `react-window` 및 `react-virtualized`와 같은 라이브러리는 이 패턴을 구현하기 위한 강력하고 사용하기 쉬운 컴포넌트를 제공합니다.

결론

리액트의 성능은 우연이 아닙니다. 그것은 가상 DOM과 효율적인 재조정 알고리즘을 중심으로 한 의도적이고 정교한 아키텍처의 결과입니다. 직접적인 DOM 조작을 추상화함으로써, 리액트는 수동으로 관리하기에는 엄청나게 복잡할 수 있는 방식으로 업데이트를 일괄 처리하고 최적화할 수 있습니다.

개발자로서 우리는 이 과정의 중요한 부분입니다. 비교(diffing) 알고리즘의 휴리스틱을 이해하고, 키를 적절하게 사용하며, 컴포넌트와 값을 메모이제이션하고, 애플리케이션을 신중하게 구조화함으로써, 우리는 리액트의 재조정자와 대항하는 것이 아니라 협력하여 작업할 수 있습니다. 파이버 아키텍처로의 진화는 가능한 것의 경계를 더욱 넓혔으며, 새롭고 유연하며 반응성이 뛰어난 UI 세대를 가능하게 했습니다.

다음에 상태 변경 후 UI가 즉시 업데이트되는 것을 보면, 잠시 시간을 내어 내부에서 일어나는 가상 DOM, 비교 알고리즘, 그리고 커밋 단계의 우아한 춤을 감상해 보세요. 이 이해는 전 세계 사용자를 위해 더 빠르고, 더 효율적이며, 더 견고한 리액트 애플리케이션을 구축하는 열쇠가 될 것입니다.